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Procetle de paiement clectronique permettant d'effectuer des transactions life 
a I'aebal de biens sur nn reseau infonnatique 

La prescnte invention ooncernc un precede dc paiemcnt electroniquc 
5 permettant d'effectuer des transactions lides a I'achal de biens offeits par des 
marcbands au moyen de services lelemaDques via un reseau de telecommunication 
infonnatique ouvcrt sur lequel sont connectes des posies serveurs dc marcbands et 
des posies clients. 

Par reseau jnformalique ouvert, on entend ici un reseau sur lequel des 
10 particuliers ou des eotreprises peuvent Iibrement se connecter a la condition de 
disposer d'une adresse, par exemple le reseau "Inleraet". Les biens concemes sont 
des produits ou des services, dont la foumiturc est realisec hors du reseau apres la 
conclusion de la transaction, ou des biens immateriels, tels que des informations, 
dont la foumiturc peut etre realisee via le reseau informatique. 
15 Diveis procides de paieraent electrODique ont tie proposes, certains 

itant deja opciationnels. 

Plusicurs proccdes sont fondes sur une nouvclle representation de la 
moruiaie. II s'agit d'une representation clectronique, quclquefois denommee "jelon" 
qui peut etre purement logicielle ou paitiellemcnt materielle, par exemple avec une 
20 carte a puce. Ces proc£des impliquenl la circulation de monnaie sur Ic reseau 
infonnatique, ce qui pose des problemes difficiles de security vis-a-vis de la 
creation dc fausse monnaie. 

D'autres precedes conrjus de paiemenl clectronique impliquent une 
relation directe avec une banque ou un reseau bancaire. Typiquement, de tels 
25 proccdes sont employes dans les rcseaux de carte dc credit comrnc, par exemple, 
des proccdes bien connus utilisant des terminaux points dc vente relics a un circuit 
carte bancaire ainsi que des proccdes utilisant des cheques electroniqucs avec unc 
signature etectronjque pour I'autbentincation dc I'acbetcur. Cest une forme dc 
lettre d'engagement emise par un acbeteur, remise au vendeur et accept£e et 
30 recortnue par une banquc. 

Les precedes qui impliquent a un moment ou un autre de la transaction 
une relation avec le systeme bancaire traditionncl et la misc en oeuvre d'une 
transaction dans ce systeme presentent des inconve'nieDts. Ainsi, les transactions 
dans le systeme bancaire ont un cout reel qui devient prohibitif lorsque le montant 
35 de l'achat est Ires faible, par exemple un montant associe a la consultation d'une 
base de donnces. Or, les rescaux informatiques sont bien adaptes a la vente de 
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bicns de faible valeur, principalement dcs biens d'information, puisque la livraison 
du bien peul se faire par lc rescau lui-meme. En outre, l'acces a un rescau banca.rt 
ou on rescau de carte bancaire doit etre hautcment protege, ce qui exclut 
pratiquement la possibility d'un acccs a travers un reseau informatiquc 
que le rescau "Internet" sur lequel dcs achcteurs potentiels peuvent se — 

L'invention a pour but de fournir un precede perroettant d'6vitcr les 
inconvements des precedes connus, cn particulitr un precede permcrtant, sans 
circulation de monnaie electronique, de realiscr de facon simple ct fiablc dcs 
transactions Iiees a l'achat dc bicns sur un reseau informatiquc et ce aussi bicn 
pour des biens de pris clcve ncccssi.ant unc autorisation par le systemc bancaire 
rraditionnei, que pour dcs biens de faible ou tres faible prix. 

Ce but est atteint grace a un procede du type defini en tele dc la 
presente description et comport ant, conformement a l'invention, les etapes de : 

- elaboration par un poste serveur de marehand connccte au reseau 
d'une demandc d'autorisation dc transaction, ou -ticket dc paieroent", conccrnaBt 
un achat envisage entre le marehand ct un client, et comportant des informations 
relatives au marehand, au client, a I'objct de l'achat et a son prix, 

- transmission du ticket de paiement via le reseau informatiquc a un 
postc serveur dc paiement distinct des postes clients ct scrvcurs dc marcnands, 

- verification automatique par le serveur de paiement si le paiement du 
prix est autorise pour le client conccmc, la verification etant cffcctuce, selon le 
montant du prix a payer, soil par interrogation d'un compte propre au client, tenu 
par le serveur dc paiement, ct destine au paiement des petits montants, soil par 
interrogation sur un rescau bancaire independant du rescau informatiquc, pour les 
paicmcnts de montants plus eleves, 

- si la verification est positive, elaboration par lc serveur dc paiement 
d'une autorisation de transaction ou bon de caisse comportant au moins unc partie 
des informations du ticket dc paiement, et 

- transmission du bon de caisse au serveur de marehand via le reseau 
I informatiquc, afin d'autoriser la realisation de l'achat . 

Ainsi, le precede selon l'invention est remarquabie en ce qu'il 
n'impliquc ni la creation de monnaie electronique, ni la circulation de monnaie 
electTOnique sur lc rescau informatiquc. 

La gestion des transactions est cffectu6c par un serveur dc paieroent 
5 qui seul peul acceder a un rcscau bancaire ou un reseau de carte bancaire, et qui 
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gerc dcs comptes clients non bancaircs sur lesquels des transactions de faibles 



Lc serveur dc paiement gerc egalement des comptes marchands non 
bancaircs utilises pour les transactions de faibles montants. Ainsi, lorsqu'un bon dc 

5 caisse est transmis apres verification pax interrogation d'un compte client tenu par 
Ic serveur de paiement, le montant dc I'achat est d£bi»6 du compte client el credits 
sur un compte marchajid propre au njaxchand concernc et tcnu par le serveur de 
paiement, cc qui n'enrraine pas des coiits de traitement Sieves. 

Chaque client dispose d'une identite qui lui est propre pour pouvoir 

0 utiliser le procede dc paiement. 11 doit egalement disposer d'un compte bancairc 
reel, de preference un compte utilisable au raoyen du systeme rraditionnel des 
cartes bancaircs. La verification par le serveur de paicmcnt peut comprendre une 
phase prcalable dc validation de I'ldentite" du client a partir du contenu du ticket de 
paicmcnt. La validation de I'identite est une operation prealablc a I'acces evenruel 

> au compte du client, si le montant de I'achat est faible, c!/ou a I'acces au reseau 
bancairc si lc montant est plus eleve. Le serveur de paiement comporle dc 
preference des moyens, par excmple une base dc donnSes, permertant de 
merooriser les relations enrrc les ideDtitfc des clients utilises pour les transactions 
sur lc reseau irrformatique et des identites bancaircs (num£ros de comptes 

> bancaircs ou numeros de cartes de credit) utilisces pour les transactions sur le 
reseau bancairc. On peut evitcr de la sortc la circulation d'identitcs bancaircs sur le 
reseau informatiquc. 

Un mode dc realisation de 1'jnvention sera Diainterjaot decrit a titre 
indicatif, mais non lirnitatif, cn reference aux dessins annexes sur lesquels : 

- la figure 1 est une vuc generate ties schematique d'un systeme de 
paicmcnt clcctronique conforme a I'invention ; 

- la figure 2 est une representation sous forme d'un schema bloc d'un 
serveur de paiement du systeme de la figure 1 ; 

- la figure 3 illustre lc d£roulement des operations relatives a un achat 
au moyen du systeme dc la figure 1 ; ct 

- les figures 4A a 4C soot des organigrammes montrant tres 
schematiquement les operations effectuSes par Ic serveur dc paiement. 

Sur la figure 1 est represents de facon trcs schematiquc un reseau de 
telecommunication informatiquc 10 sur Icquei sont connectes dcs posies scrvcurs 
de marchands 20, des postes clients 30 et au moms un poste serveur dc paiement 
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Lc rescau informatique 10 est un rescau ouvcrt ou public, par exemple 
1c reseau denommc "Internet". 

Les scrveurs de marchands 20 sont des unites telles que celles 
couramment utilisees pour des scrveurs telematiques connect* sur "Internet", par 
exemple des unites organises autour de machines "Unix" multiprocess. 

Les postes clients 30 sont essentiellement des micro-ordinalcurs qu. 
sont munis de moyens de connexion au reseau "Internet" 10, par cxerople sous 
forme d'interface "Web". Les scrveurs de marchands 20 et de postes clients 30 
utilisent par exemple des logicicls connus sous la denomination "World Wide 
Web" (WWW) utilisant le protocole HTTP. 

Le serveur de paiement 40, monlre avec plus de details sur la figure 2, 
comprend des unites frontale et dorsale respectivement 41 et 42 connectees toutes 
les deux au rescau "Internet" 10. LVnite frontale 41 a une architecture scrnblable a 
cclie d'un serveur classique connects sur un reseau tel qu'"intcn>et"". L'unitf 
dorsale 42 comporte une unite de trai.ement 43 a un ou plusieurs processeurs, une 
base de donnees 44 comportant des informations relatives aux marchands et clients 
abonnes au systeme dc paiement, un registrc de transacts 45, une unite 46 
d'interface avec un rcseau bancaire ou un reseau de carte bancaire 50, et un bus de 
communication 47 ou autre liaison sirnilaire pennetlant de relier cntre eux les 
different* constituants de 1'unite dorsale 42. Une liaison securiscc 48 pcrmet unc 
communication bidirectionnelie entre 1'unite frontale 41 et 1'unite de traitement 43. 
La communication avec le reseau inforrnatique 10 est controls par l'umte frontale 
41 tandis que la gestion dc la base dc donnees 44 ainsi que lc controle de la 
communication avec le reseau bancaire 50 sont assures par 1'unite dorsale 42. 

La base dc donnees 44 contient des informations relatives aux clients 
ct aux marchands abonnes au systeme de paiement. Pour chaque client, la base de 
donnees 44 contient 1'idcntite systeme du client ("CId"), identite" recue lore de 
I'abonnement au systeme, un comptc dc client ou porte monnaie clectrornque 
("PME") destine au paiement de faiblcs montants, une identit6 bancaire telle que 
I numero de comptc bancaire reel ou numero de carte de credit ainsi 
qu'eventuellement une clef d'acces ou mot de passe propre au client. Pour chaquc 
maichand, la base de donnees 44 contient l'identite systeme du marcband ("Mid"), 
identite recuc lors de I'abonnement au systeme, un comptc dc marchand, ou tiroir- 
caissc electronique ("TCE") destine a 1'cDcaisscment des faibles montants ct une 
i identite bancaire telle que numero dc comptc bancaire reel . 
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La figure 3 illustre scbematiquement les differentes etapes d'unc 
transaction portant sur un achat d'un bier) par un client aboruie a un marchand 
abonne. II peut s'agjr d'un bicn materiel dont la livraison au client sera effectuee 
reellement apres conclusion de la transaction ou d'un bien immaten'el (tcl que de 
5 l'inforroation) qui peut etre foumie au clieDt par le reseau iDformatique des le 
paiement electronique effectue. 

(1) Consultation par i c client 

Par connexion sur le nSseau "Internet" 10, un client peut con.su Iter en 
ligne le catalogue ou la "vitrine" d'un marchand quclconque par acces au serveur 
10 20 du marchand et par visualisation sur I'ecran du posle client 30 des biens ou 
services du marchand. Sur presentation de 1'identite CId du client, le serveur du 
marchand peut presenter au client des conditions financieres particulicrcs (par 
exemple une remise) applicable^ a la transaction eventuclle. 

(2) Demi»nde d'achat 

15 Le choix du clieDt etant arrete sur un bien O, il est rransmis au serveur 

du marchand sous forme d'un message contenant une identite Old du bien et 
I'identite CId du client. Lorsque cela est neccssaire, par exemple pour la livraison 
ulterieure du bien choisi, des informations coroplementaircs (par exemple udc 
adxesse et un horaire de livraison preferf). Cela peut etre realise de facon 
20 commode en utilisant un formulairc electronique envoye sur le reseau et destine a 
etre rempli par le client. 

Dans le cas ou 1'achat envisage represente un montant elev6 ou est 
soumis a des conditions lcgalcs, une authentifjeation prcalablc du client peut etre 
souhaitce. Comme on le vena en detail plus loin PautbcDtification d'un client est 
25 effectuee par le serveur de paiement 40. Aussi, une demande d'authentification 
proverjant d'un marchand est cmise avantageusement sous la forme d'un ticket de 
paiement de valcur nulle qui est rransmis au serveur de paiement par le reseau 
infonnatiquc via le poste client et, en cas d'authentification positive, provoque le 
ret our d'un bon de caissc du serveur de paiement au serveur marchand, toujours via 
30 le poste client. Les procedures d'etabHssement d'un ticket de paiement et de renvoi 
d'un bon de caisse sont decrites plus en detail ci-aprcs. 

La demande d'acbat eraise par ie client peut porter sur un seul bien ou 
sur plusicurs biens a fournir de facpn groupee : "achat panier". 
O) Elaboration dc la demande de paiement 
35 En rcponsc a une demande d'achat, le serveur marchand elabore une 

demande de paiement qui peut comprendre les informations suivantes : 
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- Identite du marchand, ("Mid"); 

- Description du bien commar.de, ou de chacun des biens du panier, cn 
cas d'achats groupes; 

- Type dc transaction (simple ou panier); 

- Identite du client, ("Cld"), 

- Identite du bien ou de I'ensemble des biens du panier, ("Old"); 

- Prix del'objet, ("Oid"); 

- TV A (si applicable); 

- Date et heure de remission du ticket de paiement (horodatage par le 
serveur marchand); 

- Durec de validite du ticket de paiement; 

- Numcro de serie dans le registre des ventes du marchand (notamment 
dans le cas ou la transaction a comporte une etape prealable d'authentification). 

L'enseroble des informations ci-dessus est encodec dans une chame 
; d'octets qui conslitue la chaine opaque d'un ticket de pa.cment (ou URL de 
commande de bien, URL e.an. les initiates de "Uniform Resource Locator" ou 
Localisatcur de Ressource Uniforme utilise dans les logiciels WWW avec 
protocole HTTP), comme suit: 

URL bttp : < SP> < descriptif de la commando , 
3 ou SP est 1'adresse "Internet" du serveur de paiement. Le ticket de paiement est 
adressc au poste client. II est complete par deux "ancres" logiques qui permetlent 
au client soit de l'annuler, soit dc lc confirmer. 

(d) dr. I'ordre dc paiement 

L'ordrc de paiement est transmis au serveur de paiement simplement 
5 par validation par le client de I'URL de demande dc paiement. On comprendra 
bien que le ticket de paiement ne fait alors que transiter par lc poste cl.ent. 

Sur reception d'un ordre dc paiement, le serveur de paiement 40 lc 
decode et precede a 1'authentification du client et recherche si le paiement pent etre 
«) autorise avant de rctoumcr un bon de caisse ou un refus de paiement. 

Us operations d'authentification de client et d'autorisation dc pajement 
seront decrites plus loin en detail en reference a la figure 4. 

Lorsque les verifications effectuees ne pcrmettcnt pas d'autoriser le 
paiement, une notification de refus motivee est adrcssfec au client par le serveur dc 
35 paiement (indiquant, par exemplc, compte insuffisammen. approvisionne, 
depassement d'un stuil autorise pour le client, ...) 
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Lorsque lcs venfications effectuees permettenl d'autoriser le paiemcnt, 
les informations contenues dans le ticket de paiemcnt sont completers avcc un 
numero dc scric dans lc registrc des transactions 45, une estampille horairc, uDe 
duree dc validitt (typiquement quclqucs dizaincs dc sccondes) ct le sccau du 
5 serveur de paiement constituant une information dc certification. L'enscmble dc 
ccs informations, eventuellement apres signature numcnque par I'utilisaJion dc la 
partic de clef privee d'un systeme de chiffreroent a clef privee/clef publique du 
serveur de paiement (ce qui garantit la validjle et l'jntegrite de l'autorisatjon de 
paiemcnt), est encode dans une chaine d'octets qui conslitue la chaine opaque d'un 
10 bondecaisscouURLdclivraison : 

URL http : <M> <dcscriptif du bon dc caisso , 
oil <M> est I'adresse "Internet" du marchand. 

(6) Demande de livraison 

Lc bon dc caisse est transmis au serveur du marchand via lc posle 
15 client. Ceci pcut etre effectue automatiqucment par le logiciel implante au poste 
client en utiiisant la possibility dc ic-routage des URL bicn connuc de I'bommc du 
metier. Avant d'autoriser la livraisoD du bicn, lc serveur du marcband opere un 
decodage et une verification du bon de caissc recti. Cette verification consistc a 
utiiiser la clef privee evenhjelle du serveur de paiement, a verifier que la duree de 
20 vatidit6 n'est pas ecoulee, et a rapprocber le contenu du bon de caisse avec celui de 
la demande de paiement. 

(7) Livraison tin bicn 

Lorsque le bon dc caisse est valide par le serveur du marchand, cclui- 
ci peut effectuer la livraison dircctc sur lc poste client, dans lc cas de bicn 
25 d'infonnation, ou adressc au poste client un document pennettant lc rc trait du bicn 
et precisant notarnment le lieu de livTaison ct le nom du recipiendaire. 

On notera que, dans le cas d'un achat groupi (panier), il y a creation 
par ]e serveur du marchand d'un objet avec affectation d'une identite unique. Cct 
objet est la liste dcs URL de cbacun des Mens du panier. Cest cct objet qui est 
30 indique dans 1"URL de commande dc bicn et qui permettra d'enregistrer le ddtail 
dcs biens achetes dans le registrc de transaction du serveur dc paiemcnt. 

Les figures 4A a 4C montrent les operations effcctuecs par lc serveur 
dc paiemcnt 40 en reponse a la reception d'un ordre de paiement. 

Dans l'unitf frontale 41 (figure 4A), l'ordre de paiement est decode 1 
35 (ctape 61} ct sa vaiiditc est examinee (test 62) notamraent du point dc vue de la 
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dur6c dc validite. Si le result* dc 1'examen est negatif, une notification de refus est 
envoyee au poste client (etapc 63). 

Si le resulta, dc I'examen est positif, il est precede ensuite a une 
authentication du client (c.ape 64), le detail de cefe operation e.an, dden. plus 
loin en reference a la figure 4C. Si I'au.hcnfficanon est negative (test 65), une 
notification dc refus es, envoyee au Cent (etape 63). Si elle est positive^ J<ordrc de 
paiemen, (eventuellemen, limit* a lidtmitc CId du c.ien., a hdenU.e Mid du 
marchand, e, au prix) es, transmis via la lia,son 68 a .'unite dorsale 42 du serveur 
de paiemen. represen.e sur la figure 2 (etape 66). La liaison 48 est une liarson 
i securisee interdisant I'acccs a 1'unite dorsale a toute personne se connectan, sur 1c 
reseau 10. 

L'unitc frontale 41 attend alors que 1'unite dorsale decde d'autonscr ou 
non le paiemen, (etape 67). Si le paiemen. n'es. pas au,orise, (test 68), une 
notification de refus est envoyee au peste client (etape 63). Si le paiemen, es. 
i autorise un ton de caisse es, elabore (etapc 69), u.ilisan, les mformat.ons 
enxegistrees a letape 62. Le bon de carsse es. enregistxe dans une mfimo.re de 
runite frontale 41 (ctape 70) e. es. adresse au serveur du marchand v» le pos.e 
client (etape 71). 

Au niveau de 1'unite dorsale 42 (figure 4B) du serveur de paiemen,, a la 
D reception d'un ordie de paiemen. authentifie, il es. examine si celui-ci do,, etre 
autorise a partir du comp.e client PME via le reseau bancaire 50. A cc, effet, le 
prix es, compare a un scu.l minimum (test 72). Ce seuil est par exemple de 
quelques dizaincs de francs. 

Si lc seuil est depassc, une demande pour effecruer 1'operation de 
5 paiemen, es, laocee sur le reseau bancaire (etape 73) en u.ilisan, l'iden,ite bancaire 
correspondan, a l'identite CId du client, telle qu elle ressort de la consultation de la 
base de donnees 44. A la reception de la reponse posi.ive ou negative (etape 74), 
celle-ci es, rransmise a 1'unite frontale 41 (etape 75). 

Si le seuil n'est pas depasse, le paicraent pent etre effectue a partir du 
10 compte PME du client. 

, effet, il est examine si le compte est suffisamment approvisionne 



(tes, 76). Dans la negative, un refus d'autorisation de payment, e'est-a-dnx u 
reponse negative, es, renvoyce a I'uni.e frontale (6,ape 75). Dans .'affirmative, le 
compte PME du clicn, es, debitc du prix e, le compte TCE de marchand 
corresponds, a I'iden.i.d Mid cs, cridi.e du meme mon.an, (etape 77) b 
inscrite dans le registre des transactions 45 (etape 78) et 
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I'autorisation de paicment, c'est-a-dire une rcponse positive est rransmise a l'unite 
frontaJe 41 avec I'indication du numero de serie de I'inscription dans lc regjstre de 
transactions (etape 75). 

La procedure d'authentification dans le serveur de paicment (figure 
5 4C), a l'etape 64 de la figure 4A, comprend l'envoi au poste client, de preference 
dans une forme securisec (cbiffree), d'une demande de cl£ d'acces, ou mot de passe 
(etape 641). A la reception securisec de la cl£ d'acces (£tape 642), udc comparaisOD 
est effectuee avec une information correspondantc contenuc dans la base de 
donnecs 44 (test 643). 

10 Si la comparaison est negative, ct qu'un nombre maximum de 

tcntatives infroctueuscs n'a pas ete aneint (test 644), on retoume a I'fitape 641. Si ce 
nombre maximum est atteint, 1'absence d'authentification est constatee, une alerte 
est produite (etape 645) ct unc reponse negative est envoyee au poste client (etape 
646). L'alerte peut consistcr cn une angulation du compte PME ou en une 
15 surveillance de celui-ci afin de detecter de nouvclles tcntatives d'utilisation Si le 
test a l'etapc 643 est positif, rauthentification est cnrcgistiee (etape 647) et une 
reponse positive est elaboree (etape 648). 

Des techniques de chiffrcment permettant la transmission securisec 
cfinformations numcriques sur reseau infonnatique, nolammcnt pour la demande 
20 d'envoi de cle d'acces et l'envoi de celle-ci, sont bien connues. 

La procedure d'authentification dfecrit ici pcrmct d'effectuer une 
authentification prealable d'un client dans le cas oil celle-ci est nccessaire avant 
l'fitablissement d'une demande de paiement par lc serveur du marchand. Pour cette 
authentification, il su£Dt alors en effet de creer un ticket de paiement dans lequel lc 
25 prix indique est nul, commc indique plus baut. 

L'enregjstremcDt des bons de caisse dans l'unite frontale permet aux 
clients et aux marchands de procedcr a des conrrdles et d'en obtenir 6ventuellement 
des copies. L'enregistrement des transactions dans l'unite dorsale pennet d'en 
conserver une trace en cas, par exemple, de contestation cntrc un client et un 
30 marchand. 

Les comptes clients PME gcres par le serveur de paiement ont cn 
principc un montant de soidc plafonne et, selon le mode de realisation prcfere de 
1'invention, ils ne sont pas remuneres (le systeme de paiement se rrouvant en 
dehors du monde bancaire). Un rcapprovisionnement de son compte PME par un 
35 client peut crre effectue a partir de son compte bancaire, par ordre donni a son 
ctablissement bancaire. 
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Les coraptes marthands TCE gcres par le servcur dc paiement sont 
associes a des comptes bancaires reels des marchands dans lesquels ils sont vides 
par exemple quotidiennemcnt. 

Bicn que Ton ait decrit ci-avant un mode de mise en oeuvre d'un 
precede selon 1'invention dans un environment "Internet- et avec des logiciels 
WWW utilisant le protocole HTTP, l'homme de l'art coroprendra aisemcnt que le 
precede peut etre mis en oeuvie avec un reseau informatique autre qirintemct" ou 
encore avec des logiciels serveur marchand et client n'utilisant pas le protocole 
HTTP de WWW. En outre des precedes rfaulhentification securisfc mettant en jeu 
des dispositifs matericls tels que lecteur de carte a puce ou rooyen de 
reconnaissance d'empieinte vocale pounont etre prevns a la plact dc clefc d'acefcs. 
Ccs demicres et d'autre modifications qui viendront a lesprit du l'borome du metier 
sont comprises dans la philosophic et la porlee de la presente invention. 
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REVINDICATIONS 

1. Procede de paieinent electronique pour des transactions liees a l'achat 
dc biens offerts par dcs marchands a des clients via un reseau infonnatjquc ouvert 
sur lequel son! connect es des postes serveurs de marchands ct des postes clients, 

5 caracterise par les etapes de : 

- elaboration par un poste scrvcur dc marcband connecte au rcseau 
d'une demande d'autorisatioD de transaction, ou ticket de paiement, conccmant un 
achat envisage entre le marchand et un client, ct comportant des informations 
relatives au rnarchand, au client, a l'objet de l'achat et a son prix, 

10 - transmission du ticket de paiement via le reseau informatique a un 

scrvcur de paiement distinct des posies clients et serveurs de marchands, 

- veriBcation automatique par le serveur de paiement si Ic paiement du 
prbt est autorise pour lc client concerne, la verification 6tant effectuee, selon le 
moDtant du prix a payer, soil par interrogation d'un compte client propre au client, 

15 tenu par le serveur de paiement, et destine au paiement des pctits montants, soit par 
interrogation sur un reseau bancaire independant du reseau informatique, pour les 
paiements de montants plus Aleves, 

- si la verification est positive, elaboration par le serveur de paiement 
d'une autorisation dc transaction ou bon de caisse comportant au moms une partie 

20 des informations du ticket de paiement, ct 

- transmission du bon dc caisse au scrvcur de marchand via le rcseau 
informatique, afin d'autoriser la realisation de l'achat. 

2. Procede selon la rcvendication 1, caracterise en ce que lorsqu'un bon 
de caisse est transmis apres verification par interrogation d'un compte client tenu 

25 par le serveur de paiement, le montant de l'achat est dibitc du compte client et 
credit c sur un compte marchand propre au marcband concerne et tenu par le 
serveur de paiemeDt. 

3. Procede selon 1'une quelconque des rcvendications 1 ct 2, caracterise 
en ce que la verification par le serveur de paiement comprend une phase prealable 

30 d'autbentification du client. 

4. Procede' scion la rcvendication 3, caracterise en ce que 
l'authentification est realiscc par reconnaissance d'une clef d'acces transmise par le 
reseau informatique du poste client au serveur dc paiement. 

5. Procede scion t'une quelconque dcs rcvendications 1 a 4, caracterise en 
35 ce qu'il comprend 1'elaboration par le serveur de paiement d'un bon de caisse 
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comportant au moins une partie dcs informations du ticket de paiement et une 
information dc certification. 

6 . Precede scion Tunc quclconquc dcs rcvendications 1 a 5, caracterise en 
ce qu'il comprend la memorisation par le serveur de paiement des transactions 
autorisces, par stockage d'au moins ur,e partie du contcnu dcs bons dc caisse. 

7. Precede selon l'une quelconque des rcvendications 1 a 6, caracterise en 
cc que lc ticket dc paiement est transmis du serveur du marcband au serveur de 
paiement par l'inlermediaire du poste client. 

8. Precede scion l'unc quclconquc des rcvendications 1 a 7, caracterise en 
cc que lc bon dc caisse est transmis du serveur de paiement au serveur du 
marchand par l'intermediaire du poste client. 

9 Systeme de paiement clectronique pour cffcctucr dcs transactions liees 

a 1'achat de b.ens offcrts par dcs marchands a dcs clients via un reseau infonnatique 
ouvert, le systeme comportant des posies clients et dcs postes scrveurs dc 
roarcbands pouvanl ctrc connect cs sur lc rcscau ouvert, 

systeme caracterise en ce qu'il comporte en outre au moins un poste serveur de 
paiement distinct dcs postcs clients et serveurs de marcbands et comprenant : 

- une unite frontale munie de moyens de connexion au reseau ouvert, 
-une unite dorsalc munic dc moyens dc connexion a un rcscau 

bancaire independent du rcscau ouvert, 

- dcs moyens de communication cntrc les unites frontale et dorsale, 

- des moyens de memorisation de cornptes de clients, de comptes de 



foumisseurs, ct 

- dcs moyens de rraitement pour, cn reponse a la reception par l'unile 
frontale dune demandc d'autorisation de transaction ou ticket de paiement, 
conccmant un achat envisage entic un marcband ct un client, verifier si lc paiement 
du prix est autorise pour le client conccmc par interrogation du comptc du client 
ou du rcscau bancaire et, si la verification est positive, elaborer une autorisaHon de 
transaction, ou bon de caisse afin dc la transmetlre sur lc rcscau ouvert via l'uniti 
frontale. 

10. Systeme dc paiement selon la revendication 9, caracterise cn ce que lc 

serveur de paiement comprend des moyens de memorisation dcs transactions 
autorisces. 
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